home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.20041116-20060924 / 000170_fdc@columbia.edu_Mon Oct 17 14:36:58 2005.msg < prev    next >
Internet Message Format  |  2006-09-27  |  4KB
  1. Path: newsmaster.cc.columbia.edu!not-for-mail
  2. From: Frank da Cruz <fdc@columbia.edu>
  3. Newsgroups: comp.protocols.kermit.misc
  4. Subject: Re: ftp mput /recursive problem....
  5. Date: 17 Oct 2005 18:36:42 GMT
  6. Organization: Columbia University
  7. Lines: 66
  8. Message-ID: <slrndl7rpq.d73.fdc@sesame.cc.columbia.edu>
  9. References: <dip2gm$ci$1$8300dec7@news.demon.co.uk> <slrndl29i0.ldi.fdc@sesame.cc.columbia.edu> <dirqev$7j$1$830fa7a5@news.demon.co.uk> <slrndl4vo5.mfv.fdc@sesame.cc.columbia.edu> <diuls4$fj3$1$830fa795@news.demon.co.uk> <3ZL4f.2292$h25.38@news-wrt-01.rdc-nyc.rr.com> <dj07ch$i4c$1$8302bc10@news.demon.co.uk>
  10. Reply-To: fdc@columbia.edu
  11. NNTP-Posting-Host: sesame.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 1129574202 9762 128.59.59.56 (17 Oct 2005 18:36:42 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 17 Oct 2005 18:36:42 GMT
  15. User-Agent: slrn/0.9.8.0 (SunOS)
  16. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:15414
  17.  
  18. On 2005-10-17, John Hackett <john.hackett@icon-is.co.uk> wrote:
  19. : That was my first thought when I began this and had various 
  20. : conversations with Technical Support at LaCie: but then I ran the 
  21. : complete backup with gFTP against the LaCie and it worked fine.
  22. :
  23. Perhaps gFTP is issuing a different reportoire of commands to the server
  24. and doesn't tickle the server bug, assuming there is one.
  25.  
  26. : Also, I 
  27. : have run this Kermit script against both the LaCie and another Fedora3 
  28. : server and both failed in the same way at the same point - which seems 
  29. : to suggest some problem with Kermit rather than the server.
  30. :
  31. Is it the same FTP server in both cases?
  32.  
  33. : As this was really a second line of backup I think I may give up on this 
  34. : and try a different approach - As I already have an cron'd rsync running 
  35. : to give server -> backup I think I'll just mount the LaCie on the backup 
  36. : server and use rsync to it instead. A bit less flexible for what I 
  37. : originally bought the Lacie for but unless anyone has any other bright 
  38. : ideas.....
  39. :
  40. Let's look at this transcript again:
  41.  
  42. :>>SAVED IN: /mirror/sarah/profile/Application Data/Skype/sarah_hac/
  43. :>>---> CDUP
  44. :>>250 CDUP command successful
  45. :>>
  46. :>>NOW: /mirror/sarah/profile/Application Data/Skype/
  47. :>>---> CDUP
  48. :>>250 CDUP command successful
  49. :>>
  50. :>>NOW: /mirror/sarah/profile/Application Data/
  51. :>>---> CWD Real
  52. :>>550 Real: No such file or directory
  53. :>>---> MKD Real
  54. :
  55. Kermit has CDUP'd to the server's directory:
  56.  
  57.   /mirror/sarah/profile/Application Data/ 
  58.  
  59. and now asks to CD to the "Real" subdirectory of that directory.  The server
  60. says there isn't one.  But there is, right?  So either one or more of the
  61. prior CDUP commands didn't actually work (even thought the server said they
  62. did, as Jeff said) or the server botched the CWD command, reporting the
  63. target directory did not exist when it did.  The next bit shows that the
  64. former theory is the right one:
  65.  
  66. :>>257 "/mirror/sarah/profile/Application Data/Skype/Real" - Directory
  67. :>>successfully created
  68. :>>CREATED DIRECTORY Real
  69. :>>---> CWD Real
  70. :>>250 CWD command successful
  71. :
  72. The CDUP out of the Skype subdirectory was not successful, despite the
  73. server's status report, exactly what Jeff said, which is why the CWD command
  74. did not find the Real subdirectory and therefore Kermit had to ask the
  75. server to create one.
  76.  
  77. If you can't change or fix the server, then I agree you'll have to give up
  78. on Kermit, but I don't think it's Kermit's fault.  Conceivably I could have
  79. Kermit do a PWD after each CDUP to check that the server is not lying when
  80. it says it worked, but that would slow things down a lot on certain kinds
  81. of transfers.
  82.  
  83. - Frank